Exchange Server 2010 : Fundamentals and Components of Federated Delegation (part 1)

1. Federation Trust

The following prerequisites are necessary for creating and managing the federation trust:

• The domain used for establishing a federation trust must be resolvable from the Internet. This means that the domain must be resolvable via DNS from the Internet and that the domain is registered with a domain registrar. Best practice is to use your primary SMTP domain (for example, contoso.com) rather than your internal Active Directory namespace, which may not be resolvable from the Internet (for example, contosocorp.local).

  • For cross-premises scenarios, where an organization hosts some mailboxes on site and hosts others in the Exchange Online service, it is recommended to use a sub-domain of exchangedelegation.<your primary SMTP domain> to avoid namespace conflicts with the Exchange Online tenant namespace. Your primary SMTP domain should then be added as an additional URI to your federated organization identifier using the Add-FederatedDomain cmdlet.

• You require a valid X.509 SSL certificate issued by a Certification Authority (CA) trusted by Windows Live to be able to configure a trust with the MFG. The CAs trusted by Windows Live (and, by extension, the MFG) are listed in the "Certificate Requirements for Federation Trust" section of this chapter, along with more details on the subject name requirements.

• After the federation trust is created, you must provide proof of ownership for the domain specified by creating a TXT resource record in your external DNS. This TXT record contains the application identifier (AppID) provided in the output when the federation trust is created with either the New Federation Trust Wizard or the New-FederationTrust cmdlet.

1.1. Certificate Requirements for Federation Trust

The certificate used for the federation trust must meet the following requirements:

• The certificate must be issued by a certification authority trusted by the MFG. You can obtain the most current list of trusted root Certification Authorities at http://technet.microsoft.com/en-us/library/ee332350.aspx, but the following CAs are presently trusted:

  • Comodo

  • Digicert Global Root CA

  • Digicert High Assurance EV Root CA

  • Entrust.net CA (2048)

  • Entrust Secure Server CA

  • Go Daddy Secure Certification Authority

• The certificate must have a subject key identifier field. The X.509 certificates issued by the majority of commercial CAs have this field already.

• Certificates using Cryptography Next Generation (CNG) cryptographic service providers (CSPs) aren't supported for federation; the certificate must use a CryptoAPI CSP. A CryptoAPI provider is used when you create your certificate request using the Exchange Server 2010 New Certificate Wizard.

• The certificate must use the RSA signature algorithm.

• The private key for the certificate must be exportable. This is configured automatically when you create the certificate request using the New Certificate Wizard in the EMC or the New-ExchangeCertificate cmdlet.

• The certificate must be current and valid; an expired or revoked certificate cannot be used.

• The certificate must include the enhanced key usage (EKU) type Client Authentication (1.3.6.1.5.5.7.3.2); this usage type is used for proving your identity to a remote computer. The Client Authentication usage type is included by default when you use the New Exchange Certificate Wizard in the EMC or the New-ExchangeCertificate cmdlet to generate the certificate request.

Note:

The certificate used for the federation trust does not have any subject name or subject alternative name requirements; the subject name can be the server's host name or the domain name—or any other name can be specified. When the trust is established, Exchange Server 2010 distributes the certificate to all other Exchange Server 2010 Client Access and Hub Transport servers in the organization automatically, as discussed in the Certificate Distribution section of this chapter.

1.2. Creating the Federation Trust

You create the federation trust by exchanging the X.509 certificate for your organization with the MFG, and retrieving the X.509 certificate and federation metadata from the MFG. These tasks are performed for you when you create the federation trust with the Exchange Server 2010 Exchange Management Console (EMC) or Exchange Management Shell (EMS).

In the EMC, you create the federation trust by selecting the Organization Configuration node and then clicking New Federation Trust on the Actions pane as shown in Figure 1.

In the resultant New Federation Trust Wizard (shown in Figure 2), you select the certificate used for the trust and create the trust by clicking New.

Note:

Creating a federation trust is a one-time configuration; you can only have one federation trust per Exchange Server 2010 organization. After the trust is created, the New Federation Trust option is no longer available in the EMC.

You can also create the federation trust using the New-FederationTrust cmdlet in the EMS. The parameters required for the cmdlet are -Name and –Thumbprint. -Thumbprint is the thumbprint of the certificate being used for the federation trust; to get a list of the certificates available and their thumbprints, use the following cmdlet:

Get-ExchangeCertificate | where {$_.IsSelfSigned -eq $false} | fl

After you obtain the thumbprint, the federation trust is created with the New-FederationTrust cmdlet. An example of this cmdlet for Contoso with a certificate with a thumbprint of AC00F35CBA8359953F4126E0984B5CCAFA2F4F17 is as follows:

New-FederationTrust -Name "Contoso-MFG Trust" -Thumbprint
AC00F35CBA8359953F4126E0984B5CCAFA2F4F17

After the federation trust has been successfully created, an AppID is provided in the output of the New Federation Trust Wizard (or the output of the New-FederationTrust cmdlet, if you created your federation trust using the EMS). This AppID is used in configuring your accepted domains for federation, as explained in the "Managing Federation" section of this chapter. You can also view the AppID for your organization in the Manage Federation Wizard in the EMC or by using the Get-FederationTrust cmdlet.

An example of obtaining the AppID for Contoso using the Get-FederationTrust cmdlet is as follows:

Get-FederationTrust | fl name, appl*

The output of this cmdlet should be similar to the following:

Name                  : Contoso-MFG Trust
ApplicationIdentifier : 000000004001A66A
ApplicationUri        : contoso.com